1. Field of the Invention
The present invention relates to the field of network computing, and in particular to a method and system for designing a web portal or enterprise portal comprising a hierarchical structure of portal pages and portlets for accessing web content or enterprise content accessible via the portal.
2. Related Art
FIG. 1 illustrates a schematic system view of an implementation of a web portal on a portal server in accordance with the prior art.
A prior art portal as, e.g., represented by an IBM WebSphere Portal, is provided by complex functionality implemented on a network server, such as the web server 100 illustrated in FIG. 1. The web server 100 includes logic components for user authentication 105, state handling 110, and aggregation 170 of fragments, as well as a plurality of portlets 120 provided in respective pages 125 with a respective plurality of application programming interfaces (APIs) 130, portlet container software 135, and portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required.
A portal engine of the web server 100 in FIG. 1 implements an aggregation of portlets 120 based on the underlying portal model 150 and portal information such as security settings, user roles, customization settings, and device capabilities. Within the rendered page, the portal automatically generates the appropriate set of navigation elements based on the portal model 150. The portal engine invokes portlets 120 during the aggregation as required and when required and uses caching to reduce the number of requests made to portlets. The prior art IBM WebSphere Portal employs open standards such as the Java Portlet API (Java is a registered trademark of Sun Microsystems, Inc. in the United States and other countries). It also supports the use of a remote portlet via the Web Services for Remote Portlets (WSRP) standard.
The portlet container 135 is a single control component for all portlets 120, which may control the execution of code residing in each of these portlets 120. It provides the runtime environment for the portlets 120 and facilities for event handling, inter-portlet messaging, and access to portlet instance and configuration data, among others. The portal resources 140 are in particular the portlets 120 themselves and the pages 125, on which they are aggregated in the form of an aggregation of fragments. A portal database 128 stores the portlet description, which includes, for example, attributes such as portlet name, portlet description, portlet title, portlet short title, and keywords, and the portlet interaction interface description, which is often stored in form of WSDL documents. The portal database 128 also stores the portal content structure, i.e., the hierarchical structure of portal pages, which may contain nested pages, and portlets. This data is stored in the portal database 128 in an adequate representation based on prior art techniques, such as relational tables.
The aggregation logic 170 provides all processes that are required to assemble a page 125. Typically, these processes include loading a content structure from storage, traversing the content structure, and calling the instances referenced in the content structure in order to obtain their output, which is assembled to a single page 125.
The content structure may be defined through, for example, portlet customization by an administrator.
When web applications are visited by a web user, a user is usually displayed a navigation menu that provides some means to access underlying content. A navigation menu is usually structured in a tree-like topology, and users are forced to traverse the tree in order to reach a node matching the content the user is interested in. Specifically, web portals are equipped with navigation menus which must be used to navigate through all of the contents the web portal provides.
Not every user is interested in the same content, and hence the structure which is provided for a given portal may satisfy the needs of a certain user group, but for many individual users the given topology does not satisfy their needs. Prior art techniques allow certain nodes of the topology to be blended out, i.e. blend-out a page or parts of a page (e.g., portlets). This, however is a very inflexible way to transverse the navigation tree.